The present invention relates generally to the field of operating systems and, more particularly, to a method and system for user-specified loading of an operating system.
A conventional computer system provides a user with the ability to run a variety of applications programs. In order to provide this feature effectively, however, such a computer system must be equipped with an operating system. As is well known in the art, an operating system provides central functions which are essential to operation of the computer system. The operating system controls the use of hardware resources necessary to run the application programs. For example, the operating system controls allocation of memory and processing time to the application programs. The fundamental portion of the operating system is a hardware-independent program, such as Microsoft""s MS-DOS, OS/2, etc. When this program is implemented into a computer system, it incorporates hardware-specific code that allows it to load into that computer system and correctly control the specific hardware that is a part of that computer system. The incorporation of this hardware-specific code into the hardware-independent program provides the complete, working operating system.
An example of the conventional computer system is the personal computer system illustrated in FIG. 1. The computer system shown in FIG. 1 includes a microcomputer 100, a peripheral storage device such as a disk 110, peripheral input devices such as a keyboard 120, a mouse 130, etc., and peripheral output devices such as a display monitor 140, a printer 150, etc. The microcomputer 100 contains a central processing unit (CPU) 102, a memory 104 and an input/output unit (I/O) 106. An operating system, including a hardware-independent portion such as MS-DOS, OS/2, etc., as well as a hardware-specific portion, is stored in the memory 104. The operating system contains operating system instructions which are executed by the CPU 102. Upon execution of the operating system instructions, the operating system controls, for example, allocation of the memory 104, allocation of processing time of the CPU 102, and use of the peripheral devices 110, 120, 130 and 140.
Typically, the operating system instructions which compose the operating system are initially stored on the disk 110. As such, the operating system instructions must be loaded into the memory 104 before becoming operational. When a user turns on the power of the computer system or reboots the computer system (hereinafter referred to as startup), the CPU 102 first performs an initialization process which provides this function. The initialization process, in addition to performing functions such as testing and initializing the computer system hardware, loads the operating system stored on the disk 110 into the memory 104. The operating system thereafter controls operation of the computer system to run a variety of application programs for the user.
An example of such an initialization process is the system initialization program performed by the IBM PC or by an IBM PC compatible computer system. The IBM PC is a well known computer system designed by IBM Corporation. Upon computer startup, the CPU 102 initially performs a system initialization program composed of machine-readable instructions stored in a ROM (Read Only Memory) portion of the memory 104. The system initialization program performs, in addition to various initialization and testing functions, a conventional operating system load routine which loads operating system instructions that compose an operating system from the disk 110 into the memory 104. Thereafter, the operating system instructions are executable by the CPU 102 to control allocation and use of the hardware.
A general flow diagram of the conventional operating system load routine is shown in FIG. 2. In step 202, the conventional operating system load routine (Conventional OS Load) reads a load data structure from the disk 110 into the memory 104. The load data structure contains a partition identifier which identifies an operating system partition stored on the disk 110. This operating system partition contains the operating system instructions which compose the operating system, as well as a set of machine readable instructions for loading those operating system instructions into the memory 104. In step 204, the conventional load routine reads a load record from the indicated operating system partition. The load record indicates operating system load modules stored on the operating system partition, each of which contain operating system instructions. The load record also contains load instructions for loading these operating system load modules. In step 206, the conventional load routine loads the operating system load modules indicated by the load record by executing the load instructions in the load record, upon which the operating system load routine portion of the system initialization routine is complete.
In the conventional operating system load routine explained above, a user of the computer system has no control over the process by which the operating system load modules are loaded from the disk 110 into the memory 104. That is, whichever operating system load modules are stored in the operating system partition and indicated by the load record stored therein are loaded into the memory 104. As a result of this limitation, the user has no way to specify the operating system instructions which become a part of the operating system. Thus, it is impossible for the user to enhance the operating system or correct malfunctions in the operating system prior to the time the operating system is loaded by varying the operating system instructions which are loaded into memory. For example, when the hardware-specific code does not function properly or as desired, the only option conventionally has been to replace the microchip on which the system initialization program is provided with a microchip containing an updated system initialization program.
Further, it is not possible to provide such enhancements or corrections in an optional fashion. Replacement of a microchip every time a user of the computer system wishes to change a feature of the operating system is not feasible. This problem might be solved in part by providing alternate sets of operating system load modules on different partitions on the disk 110, each set representing an alternate version of the operating system. However, such a solution has significant limitations. One limitation is that disk space is often limited on the disk on which the operating system is provided. To provide alternate versions of the operating system on different partitions would require that a large number of operating system load modules common to all versions would be redundantly stored on each version. Thus, a great deal of disk space would be wasted. Further, the conventional load record is not equipped to load an operating system from more than a limited number of partitions, or from a partition located beyond a certain location on the disk. For example, the Master Boot Record provided as the load record on conventional MS-DOS disks contains only four partition descriptors, each of which contains a single partition identifier. Thus, the Master Boot Record can reference only a limited number (4) of the partitions.
An additional problem with this approach is that the Master Boot Record contains partition identifiers of limited size, and thus cannot reference a partition with a disk address starting beyond a finite boundary (the 1024 cylinder boundary). If one or more versions of an operating system require disk space which exceeds this boundary, then no additional partitions can be referenced. As noted above, to provide alternate versions of the operating system on different partitions would require a great deal of disk space. As a result, alternate versions of the operating system are likely to be unidentifiable by the Master Boot Record. Thus, conventionally, only the single operating system partition has been implemented to store the operating system instructions that compose an operating system.
An object of the invention is to provide a user with control over the operating system instructions which compose an operating system.
Another object of the invention is to provide a user with the ability to specify which operating system load modules are loaded into memory.
Yet another object of the invention is to provide a user with the capability of enhancing or correcting an operating system prior to loading of the operating system.
Still another object of the invention is to provide a user with the capability of authorizing or denying authorization of various operating system load modules to be included in an operating system.
These and other objects are obtained by a method and system for user-specified loading of an operating system, described as follows. Operating system load modules, composed of permanent load modules and variable load modules, are stored on a disk. The permanent load modules are stored on an operating system partition on the disk, and the variable load modules are stored on one or more variable partitions on the disk. The permanent load modules and variable load modules each comprise operating system instructions. The variable load modules may implement any of a variety of optional routines which the user might wish to load, such as a device driver. Although all of the permanent load modules are included in the operating system, only variable load modules specified by the user are included in the operating system. Initially, a first variable partition is accessed and a user identifies which of the variable load modules are to be included as user-specified load modules in the operating system. Then, upon computer startup, the user-specified load modules and the permanent load modules are loaded into memory. The operating system instructions comprised by the loaded permanent load modules and user-specified load modules thus comprise the loaded operating system.